There is no 'supposed' way for this.
For gnome apps and gnome on the host, we will continue to rely on ibus as the framework that is well-integrated on the host side. So we need to make sure that im-ibus is available and enabled in the runtime

Not only that, we also need to expose the host ibus in a safe way. I guess the clients talk to it using dbus? Is the apis safe for sandboxed use?

I will look at this

Not only iBus, but also other input method engine such as scim, fcitx, ...

Here is the org.freedesktop.IBus interface:

https://github.com/ibus/ibus/blob/master/bus/ibusimpl.c#L180

The client-side im module calls CreateInputContext to create the object that it then works with.
We probably want to not allow anything beyond that in the sandbox

Here is the org.freedesktop.IBus.InputContext interface:

https://github.com/ibus/ibus/blob/master/bus/inputcontext.c#L216

I haven't looked through this in detail yet

CC @fujiwarat

There's not much of any parameter validation in the input context code, that probably needs some improvements. Eg bus_input_context_set_capabilities passes the client-provided capabilities on to the engine without filtering out any extra bits that might be set. Same for the arguments of ProcessKeyEvent and SetCursorLocation.

It is not clear to me that the InputContext.SetEngine method is called from the client-side code. If it is not needed, maybe it shouldn't be exposed.

There's not much of any parameter validation in the input context code, that probably needs some improvements.

Sounds good to me.

It is not clear to me that the InputContext.SetEngine method is called from the client-side code. If it is not needed, maybe it shouldn't be exposed.

I think an idea of a parameter likes ibus-daemon --secure to keep API.

I think an idea of a parameter likes ibus-daemon --secure to keep API.

I think maybe good to share the ibus-daemon for the sandbox and native apps.

I think an idea of a parameter likes ibus-daemon --secure to keep API.

I don't think that makes much sense, tbh. Would we run one ibus-daemon for sandboxed apps in 'secure' mode, and another one for the rest of the desktop ? If the 'secure' mode is good enough for all of the desktop, then why have the insecure mode at all ? Just drop the apis that are not needed, or add a smaller interface that we can safely expose to sandboxed apps

IIUC, only "CreateInputContext" method of "org.freedesktop.IBus" interface is allowed in the sandbox.

Also I think "BecomeMonitor" method of "org.freedesktop.DBus" interface should be disallowed.

What do you mean ? Are you saying ibus already has special code to handle being inside a sandbox ? where is that code ?

Sorry, I just try to summarize my understanding, and made a spelling mistake, corrected it now.

then why have the insecure mode at all ?

Probably we will keep ibus_input_context_set_engine() and InputContext.SetEngine() until the version is bumped. Currently we have no plan to update the IBus version to 1.6 for a while.

I mean --secure option would be an idea if you like to drop the API immediately since currently we have no plan to bump the version.
Seems you don't bustle up the implementation so I cancel that idea now.

What do you mean ?

I think he put his idea not to allow CreateInputContext beyond that in the sandbox since "BecomeMonitor" method is used by dbus-monitor.

Here is a concern that alex mentioned on irc:

clients probably get a path to the context object, and can easily guess other clients context paths - what happens if they make calls there ?

I was misstating things a bit, I think.

We actually need to use a separate unique bus name to prevent the client from talking to other, 'unsafe' interfaces. So, the suggestion is have a separate bus connection, take a different well-known name, and expose limited, safe interfaces on that name. And strictly validate that clients only make calls on 'their' objects.

Here is how the context object paths get created:

src/ibusshare.h:#define IBUS_PATH_INPUT_CONTEXT "/org/freedesktop/IBus/InputContext_%d"

bus/inputcontext.c: gchar *path = g_strdup_printf (IBUS_PATH_INPUT_CONTEXT, ++id);

And I can't find any validation that would check that Inputcontext calls are coming from the owner of the context.

An extra complication here is that ibus is using not just its own bus but its own daemon implementation which may or may not cause us extra problems when proxying - d-feet certainly has issues talking to it.

For d-feet, we filed a bug before and write a draft patch for it.

URL: https://bugzilla.redhat.com/show_bug.cgi?id=1111033

CC'ing @phuang

That d-feet patch seems wrong. Instead of making d-feet connect to unsupported addresses, why not make ibus provide a supported one ? Or, if that is hard, make gio support the address in question.

You can already get d-feet to connect to ibus by doing

DBUS_SESSION_BUS_ADDRESS=$IBUS_ADDRESS d-feet

That is how I did my initial investigation of ibus protocol.

From irc:

alexlarsson> mclasen: honestly, the right way would probably to use a per-client connection instead of a separate bus
mclasen> ok
alexlarsson> just do the create-context on the normal bus
then pass an fd to the client for dbus connection
mclasen> there's multiple contexts in an app
alexlarsson> and make sure you only allow access to that context from that fd
mclasen> I think
alexlarsson> so, one peer connection per unique id then
and then only handle the context:es for that connection from that connection
if you know what i mean

A longer-term perspective for wayland is that this should really move to the compositor, and use the text protocol. That would solve the sandboxing issues for good.

To clarify some of the last comments:

We want: one peer-to-peer connection per client (ie per application), not one per context (it turns out that clients generally use many contexts (one per text field)).

I tried to get a dbus address per client with the following way:
https://github.com/fujiwarat/ibus/commits/dedicated-bus

1. Get a shared dbus address from $XDG_CONFIG_HOME/ibus/bus/*
2. Connect ibus-daemon with the shared dbus address.
3. Get a dedicted dbus address from the shared connection.
4. Connect ibus-daemon with the dedicated dbus address.

But the packet is still readable by dbus-monitor with the shared dbus address.

I just read the comments of dbus-proxy recently.
Will ibus also use dbus-proxy for filtering?

Is it not secure to expose non-well-known names
to ibus client through dbus-proxy,
such as "/org/freedesktop/IBus/InputContext_%d"?

Will ibus also use dbus-proxy for filtering?

I don't know how to use dbus-proxy. I guess g_dbus_connection_add_filter() does not help to avoid dbus-monitor.

Is it not secure to expose non-well-known names to ibus client through dbus-proxy,

Right. But primarily I'm thinking to access by client.

I tried flatpak run org.gnome.gedit command and understood it runs /usr/libexec/flatpak-dbus-proxy internally.
My understanding is flatpak-dbus-proxy sets the policy of "org.gnome.gedit*" to FLATPAK_POLICY_OWN but seems the dbus methods whose destination is "org.gnome.gedit*" are called three times only.
I can see most packets with dbus-monitor --address 'unix:path=/run/user/$UID/bus' but don't see any differences between flatpak run org.gnome.gedit and flatpak --socket=session-bus run org.gnome.gedit, the latter works without any filters as far as I understand.

Is it a good example to test flatpak-dbus-monitor?

Is it a expected result that dbus-monitor can observe the most packets of ibus?
If yes, I do not understand what we try to restrict in the dbus connection but maybe my patch is fine at the moment.

I built the gtk3 im-module into the freedesktop runtime now. I guess we should add the gtk2 one to the gnome runtime also.

I built the gtk3 im-module into the freedesktop runtime now. I guess we should add the gtk2 one to the gnome runtime also.

Yes. Also /usr/libexec/ibus-x11 and /usr/lib64/qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so too.

What exactly does ibus-x11 do?

ibus-x11 communicates with X clients and ibus-daemon for the key events with XIM and IBus protocols.
X application (X11 or Java) <=> X server <=> ibus-x11 <=> ibus-daemon
You have to set XMODIFIERS environment variable. E.g. env XMODIFIERS=@im=ibus xterm

Now Fedora IBus RPM includes ibus-portal.
Do Fedora and upstream Flatpak enable IBus?

The very latest runtimes should have ibus support, yes.

Thank you. I forgot to copy ibusimcontext.c to client/gtk3 in fedora build.

Which are the first flatpak and ibus releases that support this?

@juhp Ibus 1.5.17, and it is independent on the flatpak version, but needs a recent flatpak runtime with the ibus version in it (should be ok with e.g. freedesktop.org 1.6 runtimes and gnome >= 3.24 runtimes).

Hello, I still can't use ibus in Slack flatpak app, I think both ibus and Slack flat app are latest version:

• ibus

zhiwei@deepin:~$ ibus version
IBus 1.5.18
zhiwei@deepin:~$ dpkg -l | grep ibus
ii  gir1.2-ibus-1.0:amd64                                  1.5.18-1                             amd64        Intelligent Input Bus - introspection data
ii  ibus                                                   1.5.18-1                             amd64        Intelligent Input Bus - core
ii  ibus-clutter:amd64                                     0.0+git20090728.a936bacf-5.1+b2      amd64        ibus input method framework for clutter
ii  ibus-gtk:amd64                                         1.5.18-1                             amd64        Intelligent Input Bus - GTK+2 support
ii  ibus-gtk3:amd64                                        1.5.18-1                             amd64        Intelligent Input Bus - GTK+3 support
ii  ibus-qt4                                               1.3.3-1+b1                           amd64        qt-immodule for ibus (QT4) (plugin)
ii  ibus-rime                                              1.2-1+b1                             amd64        Rime Input Method Engine for IBus
ii  libgusb2:amd64                                         0.2.11-1                             amd64        GLib wrapper around libusb1
ii  libibus-1.0-5:amd64                                    1.5.18-1                             amd64        Intelligent Input Bus - shared library
ii  libibus-qt1                                            1.3.3-1+b1                           amd64        qt-immodule for ibus (QT4) (library)

• com.slack.Slack

zhiwei@deepin:~$ flatpak info com.slack.Slack 
Ref: app/com.slack.Slack/x86_64/stable
ID: com.slack.Slack
Arch: x86_64
Branch: stable
Origin: flathub
Date: 2018-10-08 13:27:56 +0000
Subject: Update to 3.3.3 (9dc0519c)
Commit: af79c798127613ed8f87418ee2406b1ef52c3781d8a054ce727a08cd5409b0fb
Parent: 597977f6d80c3df3c890df167b30240c6f503da12172fbf8fc2782402f91f651
Location: /var/lib/flatpak/app/com.slack.Slack/x86_64/stable/af79c798127613ed8f87418ee2406b1ef52c3781d8a054ce727a08cd5409b0fb
Installed size: 2.8 MB
Runtime: org.freedesktop.Platform/x86_64/18.08

There Slack ibus/bus directory was created .var/app/com.slack.Slack/config/ibus/bus/ but nothing inside, and I tried to cp .config/ibus/bus/312142facf6a41b9b8ea773d842a66de-unix-0 .var/app/com.slack.Slack/config/ibus/bus/, but still can't use ibus.

Update: I can use ibus in org.gnome.gedit flat app.

Can someone give me some advice about this issue?

Can someone give me some advice about this issue?

This bug has been closed for a year, and there's a link about Electron apps just above your comment. Following that link would be a good first step. File a separate bug if your issue is a separate problem.

Why is it closed, I still can't input Chinese in the flatpak version of OBS Studio, Steam, whatever else.
OS: Ubuntu 18.04.1

Why is it closed, I still can't input Chinese in the flatpak version of OBS Studio, Steam, whatever else.

It's closed because the IBus support got mrged. If you have further problems, file a bug. I'm guessing that in this case, you should file an issue against your distribution, as IBus input works on other distributions.

Having the same issue as well, on Fedora 29.
Filed a bug to Red Hat Bugzilla already.
https://bugzilla.redhat.com/show_bug.cgi?id=1647627

Let's move discussion on the Electron apps issue to #1671.